This breaks the independent vsc extension purpose, user need to install python in it's own pc and do the pip install etc, not plug and play, it will not work for all due to the reason I explain in #22

This breaks the independent vsc extension purpose, user need to install python in it's own pc and do the pip install etc, not plug and play, it will not work for all due to the reason I explain in #22

How hard is it for a user to run "pip install" when they have python? If you check the diff - it even gives you a command to copy and paste in your terminal?

This breaks the independent vsc extension purpose, user need to install python in it's own pc and do the pip install etc, not plug and play, it will not work for all due to the reason I explain in #22

How hard is it for a user to run "pip install" when they have python? If you check the diff - it even gives you a command to copy and paste in your terminal?

It's not how hard, some JS hardcore dev are not even care about it, they wont use it, in addition some people that use miniconda dont want to change their base. This was intended to plug and play, no other necessary action so it can cover all of them.

Add the deps back then - or add a build path to bundle deps (and not in repo directly) in a visx that's not the published version - (but is healthier to NOT include it) and undo the dep checks...) you can keep the cleaner build stuff.....

The goal here is to make the extension lighter and easier to maintain over time rather than to make it harder to use.

I agree the original design was aiming for “pure plug‑and‑play”. The problem is we have to vendor a full copy of requests / urllib3 / charset_normalizer inside the VSIX and keep those wheels updated ourselves.

That’s awkward for security updates and makes the extension heavier.

The new flow moves us to the more standard VS Code pattern:

You choose which Python to use via contextEngineUploader.pythonPath (this can be any conda env / venv / system Python, not necessarily base).

On startup we check for the three required modules.
If they’re missing, we show a clear error and offer a one‑click “Copy install command” with the exact python -m pip install requests urllib3 charset_normalizer to run in that env.
So yes, it’s no longer literally zero‑action, but for anyone who has Python installed it’s a one‑time pip install and then it just works. In exchange, we avoid shipping and maintaining a private Python dependency tree inside the extension.

If we later decide we really need a completely self‑contained option for pure JS users, we can look at a separate packaged client / devcontainer path. For now I’d prefer to keep the extension lighter and rely on the user’s Python in a way that’s explicit and easy to debug.

I get the motivation around keeping the extension lighter and avoiding vendoring dependencies, but my priority for this project is plug‑and‑play UX for end users.

1.6 MB of vendored deps is small in VS Code extension terms, and for this project I think that size is considerable accepted for the cost to keep the experience as simple as possible.

To avoid pain maintaining python_libs, we can automate it in CI and have a small script / workflow that runs:

python -m pip install -t vscode-extension/context-engine-uploader/python_libs \
    requests urllib3 charset_normalizer

So we’re not manually managing those wheels. CI refreshes them when you bump versions. Later we can decide to remove the Python dependency entirely (e.g. ship binaries;which still has increase in size or rewrite it in Node/TS client), I meant for now to optimize for “install and it just works”, not for minimizing the vsix size or pushing dependency management to the user.

since this case was easy for us:

On startup we check for the three required modules.
If they’re missing, we show a clear error and offer a one‑click “Copy install command” with the exact python -m pip install requests urllib3 charset_normalizer to run in that env.
So yes, it’s no longer literally zero‑action, but for anyone who has Python installed it’s a one‑time pip install and then it just works. In exchange, we avoid shipping and maintaining a private Python dependency tree inside the extension.

but not for others, I've convinced and try to implemented this on my team, this is a real situation that happens.

Given we already require a Python runtime and a running upload service, I think a one‑time pip install is a reasonable trade‑off for a cleaner, more maintainable extension.

If your team has stricter constraints and really needs vendored deps, that might be better handled in a separate pipeline or fork, rather than as the only official distribution.

I’m personally OK with a slightly larger VSIX if we decide to bundle deps at build time. What I’d like to avoid is committing those deps into the repo.

Would you be OK with a build script that grabs the deps and packages them into a .vsix (which we may/may not publish on the marketplace) for offline use — just drop the file into VS Code? That would just mean adding a deps step to the build script so the repo stays clean, but the offline VSIX can still be fully self‑contained.

Would you be OK with a build script that grabs the deps and packages them into a .vsix (which we may/may not publish on the marketplace) for offline use — just drop the file into VS Code? That would just mean adding a deps step to the build script so the repo stays clean, but the offline VSIX can still be fully self‑contained.

Yes, I totally agree with this, this what I proposed in my previous comments, I agree with you not to put the python-libs in the repository. By this we can achieve the goals

I added an arg to bundle the deps in - it's up to repo owner if the deps are included in the marketplace version - the deps won't be sitting into the repo now though